Testing ViewModels, Business Logic, and Data Services

Course: iOS App Development

Topic: Testing ViewModels, Business Logic, and Data Services

Course Link: iOS Training – JustAcademy

Demo Link: Register for Course Demo

Website: JustAcademy Official Website

1. Introduction to Testing ViewModels, Business Logic, and Data Services

Modern iOS applications are commonly developed using architectural patterns such as Model-View-ViewModel (MVVM), Model-View-Controller (MVC), and Clean Architecture. These patterns divide an application into different responsibilities so that developers can maintain, extend, and test the code more effectively.

In an MVVM-based iOS application, the View displays information and receives user interactions, the ViewModel manages presentation-related state and coordinates application behavior, business logic implements application rules, and data services communicate with external systems such as APIs, databases, and local storage.

Testing these components independently helps developers identify problems without always launching the complete application or interacting with its user interface. It also makes the application easier to maintain because changes in one component can be verified without manually testing every screen.

Learning Objectives

• Understand the responsibilities of ViewModels, business logic, and data services.
• Learn how to design testable iOS application architecture.
• Understand dependency injection and protocol-based development.
• Write unit tests for ViewModels using XCTest and Swift Testing.
• Test business rules, calculations, and validation logic.
• Test data services and repository implementations.
• Use mocks, stubs, and fakes to isolate application components.
• Test asynchronous operations using async/await.
• Verify loading, success, empty, and error states.
• Understand test coverage and test organization in Xcode.
• Build a practical testing workflow for an iOS application.

2. Understanding the Main Components of an iOS Application

Before writing tests, developers should understand the responsibilities of the components being tested. Separating responsibilities makes it easier to create focused tests and identify the source of a failure.

2.1 View

The View represents the user interface. It displays information, receives user input, and communicates user actions to the ViewModel.

In SwiftUI, views are commonly created using components such as Text, Button, TextField, List, VStack, and NavigationStack. In UIKit, views are managed through UIView, UIViewController, and related interface components.

2.2 ViewModel

The ViewModel prepares data for the View, manages presentation state, and coordinates operations such as loading records, submitting forms, and refreshing information.

A ViewModel should generally avoid directly managing interface rendering details or implementing large amounts of unrelated business logic. Keeping these responsibilities separate makes ViewModels easier to test.

2.3 Business Logic

Business logic contains the rules that determine how an application should behave. It may include calculations, eligibility checks, pricing rules, validation, discount calculations, account restrictions, and order-processing rules.

Business logic should ideally be independent of SwiftUI, UIKit, and external services so that it can be tested using simple input values and expected results.

2.4 Data Services

Data services handle communication with external or local data sources. They may retrieve information from REST APIs, save records to databases, read files, manage authentication, or access local storage.

Testing data services helps verify that requests, response decoding, error handling, and data transformations work correctly.

Component Responsibility Table

3. Understanding Why These Components Need Separate Testing

Testing only the user interface does not provide sufficient coverage of all application logic. A screen may appear correctly while its calculations, API handling, or data transformation contain errors.

Separate component testing allows developers to verify the actual behavior of each layer.

Benefits of Testing Each Component

• Faster Feedback: Small tests usually execute faster than complete application workflows.
• Better Error Identification: Developers can identify whether a failure belongs to the ViewModel, business logic, or data service.
• Reduced Dependencies: Components can be tested without requiring a real server or database.
• Improved Maintainability: Tests document the expected behavior of important application components.
• Regression Protection: Existing functionality can be checked after code changes.
• Reliable Refactoring: Developers can improve internal implementation while preserving expected behavior.
• Better Architecture: Testability encourages separation of responsibilities and loose coupling.

4. Understanding MVVM Architecture for Testing

MVVM is a common architectural pattern used in SwiftUI and can also be applied to UIKit applications. It separates the user interface from presentation logic and application data.

MVVM Architecture Components

• Model: Represents application data and domain entities.
• View: Displays information and receives user interactions.
• ViewModel: Prepares data, manages screen state, and coordinates operations.

Example MVVM Workflow

1. The user opens the product screen.
2. The ViewModel receives a request to load products.
3. The ViewModel calls a repository or service.
4. The repository retrieves product data.
5. The ViewModel updates its presentation state.
6. The View observes the updated state.
7. The user sees the loaded product information.

MVVM Testing Structure

5. Understanding Dependency Injection

Dependency injection is a technique in which an object receives the dependencies it needs from an external source instead of creating those dependencies internally.

It is especially important for testing ViewModels and data services because it allows developers to replace real network services or database implementations with controlled test objects.

Example Without Dependency Injection

final class ProductViewModel {

    private let service = ProductAPIService()

    func loadProducts() async throws {
        // Uses the real service directly.
    }
}

This implementation creates a dependency internally. Testing it may require a real network connection or changes to the service implementation.

Example With Dependency Injection

protocol ProductService {
    func fetchProducts() async throws -> [Product]
}

final class ProductViewModel {

    private let service: ProductService

    init(service: ProductService) {
        self.service = service
    }

    func loadProducts() async throws {
        let products = try await service.fetchProducts()
        print(products)
    }
}

Now the ViewModel can receive either a real service or a test implementation. This makes the component easier to test and reduces its dependence on external systems.

Benefits of Dependency Injection

• Allows real and mock dependencies to be substituted.
• Reduces tight coupling between components.
• Makes unit tests easier to write.
• Improves code reusability.
• Supports different configurations for development, testing, and production.
• Reduces dependence on global shared state.

6. Understanding Protocol-Based Testing

Protocols define a contract that different types can implement. In testing, protocols are useful because the application can depend on an abstraction instead of a specific concrete implementation.

Example: Product Service Protocol

import Foundation

struct Product: Codable, Equatable {
    let id: Int
    let name: String
    let price: Double
}

protocol ProductService {
    func fetchProducts() async throws -> [Product]
}

The ProductService protocol defines the operation required by the ViewModel. A real API service and a mock service can both conform to this protocol.

Real Service Implementation

final class ProductAPIService: ProductService {

    func fetchProducts() async throws -> [Product] {

        let url = URL(
            string: "https://example.com/api/products"
        )!

        let (data, response) = try await URLSession.shared.data(
            from: url
        )

        guard let httpResponse = response as? HTTPURLResponse,
              (200...299).contains(httpResponse.statusCode) else {
            throw URLError(.badServerResponse)
        }

        return try JSONDecoder().decode(
            [Product].self,
            from: data
        )
    }
}

The example uses a placeholder API address. A production application should replace it with the actual backend endpoint and configure request headers, authentication, and other required networking behavior.

7. Understanding the Arrange-Act-Assert Testing Pattern

Arrange-Act-Assert (AAA) is a simple structure for organizing individual test cases. It helps make tests readable and ensures that each test has a clear purpose.

7.1 Arrange

Prepare the objects, input values, and dependencies needed for the test. This may include creating a ViewModel and configuring a mock service.

7.2 Act

Execute the method or operation being tested. For example, call loadProducts() or calculateDiscount().

7.3 Assert

Compare the actual result with the expected result using assertions or expectations.

Example

func testProductCount() {

    // Arrange
    let products = [
        Product(id: 1, name: "iPhone", price: 70000),
        Product(id: 2, name: "iPad", price: 50000)
    ]

    // Act
    let count = products.count

    // Assert
    XCTAssertEqual(count, 2)
}

8. Testing Business Logic in iOS Applications

Business logic is the core set of rules that determines how application data should be processed. It should be tested independently from the interface and external services whenever possible.

Examples of Business Logic

• Calculating product prices and discounts.
• Checking whether a user is eligible for a service.
• Validating registration information.
• Calculating shopping cart totals.
• Applying tax and delivery charges.
• Checking subscription eligibility.
• Calculating booking costs.
• Determining order status.

8.1 Creating a Business Logic Component

Consider an e-commerce application that provides discounts to customers. Instead of placing discount calculations inside a SwiftUI View, create a separate type responsible for pricing rules.

import Foundation

struct PriceCalculator {

    func calculateDiscount(
        price: Double,
        percentage: Double
    ) -> Double {

        guard price >= 0,
              percentage >= 0,
              percentage <= 100 else {
            return 0
        }

        return price * percentage / 100
    }

    func calculateFinalPrice(
        price: Double,
        percentage: Double
    ) -> Double {

        guard price >= 0,
              percentage >= 0,
              percentage <= 100 else {
            return 0
        }

        let discount = calculateDiscount(
            price: price,
            percentage: percentage
        )

        return price - discount
    }
}

8.2 Writing Unit Tests for Business Logic

import XCTest
@testable import MyIOSApp

final class PriceCalculatorTests: XCTestCase {

    var calculator: PriceCalculator!

    override func setUp() {
        super.setUp()
        calculator = PriceCalculator()
    }

    override func tearDown() {
        calculator = nil
        super.tearDown()
    }

    func testDiscountCalculation() {

        let discount = calculator.calculateDiscount(
            price: 1000,
            percentage: 10
        )

        XCTAssertEqual(discount, 100)
    }

    func testFinalPriceCalculation() {

        let finalPrice = calculator.calculateFinalPrice(
            price: 1000,
            percentage: 10
        )

        XCTAssertEqual(finalPrice, 900)
    }

    func testZeroDiscount() {

        let finalPrice = calculator.calculateFinalPrice(
            price: 1000,
            percentage: 0
        )

        XCTAssertEqual(finalPrice, 1000)
    }

    func testFullDiscount() {

        let finalPrice = calculator.calculateFinalPrice(
            price: 1000,
            percentage: 100
        )

        XCTAssertEqual(finalPrice, 0)
    }

    func testNegativePrice() {

        let finalPrice = calculator.calculateFinalPrice(
            price: -100,
            percentage: 10
        )

        XCTAssertEqual(finalPrice, 0)
    }

    func testInvalidDiscountPercentage() {

        let finalPrice = calculator.calculateFinalPrice(
            price: 1000,
            percentage: 150
        )

        XCTAssertEqual(finalPrice, 0)
    }
}

8.3 Testing Boundary Conditions

Boundary testing checks values at the limits of accepted input ranges. Many business-logic defects occur when values are exactly at a minimum, maximum, or transition point.

For a discount calculator, useful boundary cases include:

• Price equal to zero.
• Price greater than zero.
• Negative price.
• Discount equal to zero percent.
• Discount equal to one hundred percent.
• Discount greater than one hundred percent.
• Negative discount percentage.

8.4 Testing Validation Rules

Validation logic is another important area of business logic. It checks whether user-provided information satisfies application requirements.

import Foundation

struct RegistrationValidator {

    func isValidName(_ name: String) -> Bool {

        return !name.trimmingCharacters(
            in: .whitespacesAndNewlines
        ).isEmpty
    }

    func isValidPassword(_ password: String) -> Bool {

        return password.count >= 8
    }

    func passwordsMatch(
        password: String,
        confirmation: String
    ) -> Bool {

        return password == confirmation
    }
}

Testing Registration Validation

import XCTest
@testable import MyIOSApp

final class RegistrationValidatorTests: XCTestCase {

    let validator = RegistrationValidator()

    func testValidName() {

        XCTAssertTrue(
            validator.isValidName("Rahul")
        )
    }

    func testEmptyName() {

        XCTAssertFalse(
            validator.isValidName("   ")
        )
    }

    func testValidPassword() {

        XCTAssertTrue(
            validator.isValidPassword("Password123")
        )
    }

    func testShortPassword() {

        XCTAssertFalse(
            validator.isValidPassword("123")
        )
    }

    func testMatchingPasswords() {

        XCTAssertTrue(
            validator.passwordsMatch(
                password: "Password123",
                confirmation: "Password123"
            )
        )
    }

    func testDifferentPasswords() {

        XCTAssertFalse(
            validator.passwordsMatch(
                password: "Password123",
                confirmation: "Password456"
            )
        )
    }
}

9. Testing Business Logic with Swift Testing

Swift Testing provides a modern way to write unit tests using Swift macros. It supports test functions, test suites, expectations, and parameterized testing.

Example Using @Test and #expect

import Testing
@testable import MyIOSApp

struct PriceCalculatorSwiftTests {

    @Test
    func calculateDiscount() {

        let calculator = PriceCalculator()

        let result = calculator.calculateDiscount(
            price: 2000,
            percentage: 10
        )

        #expect(result == 200)
    }

    @Test
    func calculateFinalPrice() {

        let calculator = PriceCalculator()

        let result = calculator.calculateFinalPrice(
            price: 2000,
            percentage: 10
        )

        #expect(result == 1800)
    }
}

Parameterized Testing

Parameterized testing allows one test function to execute with multiple sets of input values. It is particularly useful for business logic with several valid and invalid conditions.

import Testing
@testable import MyIOSApp

struct PriceCalculatorParameterizedTests {

    @Test(arguments: [
        (1000.0, 10.0, 900.0),
        (2000.0, 20.0, 1600.0),
        (500.0, 0.0, 500.0),
        (1000.0, 100.0, 0.0)
    ])
    func finalPriceTest(
        price: Double,
        discount: Double,
        expected: Double
    ) {

        let calculator = PriceCalculator()

        let result = calculator.calculateFinalPrice(
            price: price,
            percentage: discount
        )

        #expect(result == expected)
    }
}

10. Understanding ViewModel Testing

A ViewModel manages the data and state that a user interface displays. It usually coordinates user actions, calls business logic or repositories, and updates the screen state.

ViewModel testing focuses on verifying whether the ViewModel responds correctly to different inputs and dependency results.

Important ViewModel Testing Areas

• Initial state of the ViewModel.
• Loading state when an operation starts.
• Successful data loading.
• Empty data responses.
• Error handling.
• Form validation and submission.
• Correct calls to dependencies.
• State updates after user actions.
• Retry behavior after failures.
• Prevention of unexpected duplicate operations.

10.1 Creating a Product ViewModel

First, define the product model and service protocol.

import Foundation

struct Product: Codable, Equatable, Identifiable {
    let id: Int
    let name: String
    let price: Double
}

protocol ProductService {
    func fetchProducts() async throws -> [Product]
}

Next, create a ViewModel that manages product loading and presentation state.

import Foundation

@MainActor
final class ProductViewModel: ObservableObject {

    enum State: Equatable {
        case idle
        case loading
        case loaded([Product])
        case empty
        case failed(String)
    }

    @Published private(set) var state: State = .idle

    private let service: ProductService

    init(service: ProductService) {
        self.service = service
    }

    func loadProducts() async {

        state = .loading

        do {

            let products = try await service.fetchProducts()

            if products.isEmpty {
                state = .empty
            } else {
                state = .loaded(products)
            }

        } catch {

            state = .failed(error.localizedDescription)
        }
    }
}

10.2 Understanding ViewModel States

11. Creating Mock Services for ViewModel Tests

A mock service is a test implementation that replaces the real dependency. It allows developers to control the data returned to the ViewModel and verify how the ViewModel responds.

11.1 Mock Service Returning Successful Data

import Foundation
@testable import MyIOSApp

final class MockProductService: ProductService {

    var productsToReturn: [Product] = []
    var shouldThrowError = false

    func fetchProducts() async throws -> [Product] {

        if shouldThrowError {
            throw URLError(.notConnectedToInternet)
        }

        return productsToReturn
    }
}

This mock supports three important testing scenarios:

• Returning a list of products.
• Returning an empty list.
• Throwing an error.

11.2 Testing Initial ViewModel State

import XCTest
@testable import MyIOSApp

@MainActor
final class ProductViewModelTests: XCTestCase {

    func testInitialStateIsIdle() {

        let service = MockProductService()
        let viewModel = ProductViewModel(
            service: service
        )

        XCTAssertEqual(viewModel.state, .idle)
    }
}

11.3 Testing Successful Data Loading

import XCTest
@testable import MyIOSApp

@MainActor
final class ProductLoadingTests: XCTestCase {

    func testLoadProductsSuccessfully() async {

        let service = MockProductService()

        service.productsToReturn = [
            Product(
                id: 1,
                name: "iPhone",
                price: 70000
            ),
            Product(
                id: 2,
                name: "iPad",
                price: 50000
            )
        ]

        let viewModel = ProductViewModel(
            service: service
        )

        await viewModel.loadProducts()

        XCTAssertEqual(
            viewModel.state,
            .loaded(service.productsToReturn)
        )
    }
}

11.4 Testing Empty Data

import XCTest
@testable import MyIOSApp

@MainActor
final class ProductEmptyStateTests: XCTestCase {

    func testEmptyProductResponse() async {

        let service = MockProductService()
        service.productsToReturn = []

        let viewModel = ProductViewModel(
            service: service
        )

        await viewModel.loadProducts()

        XCTAssertEqual(
            viewModel.state,
            .empty
        )
    }
}

11.5 Testing Error Handling

import XCTest
@testable import MyIOSApp

@MainActor
final class ProductErrorTests: XCTestCase {

    func testServiceFailureUpdatesViewModel() async {

        let service = MockProductService()
        service.shouldThrowError = true

        let viewModel = ProductViewModel(
            service: service
        )

        await viewModel.loadProducts()

        if case .failed(let message) = viewModel.state {
            XCTAssertFalse(message.isEmpty)
        } else {
            XCTFail("Expected failed state.")
        }
    }
}

12. Testing ViewModel State Transitions

State transition testing verifies that a ViewModel moves through the correct states when an operation starts, completes, or fails.

For example, a product-loading operation should move from idle to loading and then to loaded, empty, or failed.

Example State Transition Flow

idle
  |
  v
loading
  |
  +------> loaded(products)
  |
  +------> empty
  |
  +------> failed(error)

Important State Transition Test Cases

13. Testing Asynchronous ViewModels

ViewModels frequently perform asynchronous operations such as API requests, database queries, file loading, and authentication.

When a ViewModel uses Swift concurrency, its asynchronous methods can be tested using async test methods. The test should wait for the operation to complete before verifying the final state.

Example: Async ViewModel Test

import XCTest
@testable import MyIOSApp

@MainActor
final class AsyncProductViewModelTests: XCTestCase {

    func testAsyncProductLoading() async {

        let service = MockProductService()

        service.productsToReturn = [
            Product(
                id: 10,
                name: "MacBook",
                price: 120000
            )
        ]

        let viewModel = ProductViewModel(
            service: service
        )

        await viewModel.loadProducts()

        guard case .loaded(let products) = viewModel.state
        else {
            XCTFail("Expected loaded state.")
            return
        }

        XCTAssertEqual(products.count, 1)
        XCTAssertEqual(products[0].name, "MacBook")
    }
}

Testing Callback-Based Operations

Some older services use completion handlers instead of async/await. XCTest expectations can be used to wait for callback-based operations.

import XCTest

final class CallbackTestingExample: XCTestCase {

    func testCallbackOperation() {

        let expectation = expectation(
            description: "Callback should complete"
        )

        let operation = DispatchQueue.global()

        operation.async {

            let result = "Operation completed"

            XCTAssertEqual(
                result,
                "Operation completed"
            )

            expectation.fulfill()
        }

        wait(for: [expectation], timeout: 3)
    }
}

For Swift concurrency-based code, prefer async test methods when possible. Expectations remain useful for callbacks, delegate methods, notifications, and other asynchronous APIs without a direct async/await interface.

14. Testing Data Services

Data services are responsible for retrieving, sending, updating, and deleting application data. They often communicate with backend APIs or local storage systems.

Testing a data service helps verify whether requests are created correctly, responses are handled correctly, and errors are reported in a predictable way.

Important Data Service Testing Areas

• Correct API endpoint construction.
• HTTP method and request configuration.
• Request headers and authentication information.
• Successful HTTP responses.
• HTTP error responses.
• Invalid or unexpected JSON data.
• Network connectivity failures.
• Timeout handling.
• Data decoding and model mapping.
• Empty responses and missing fields.
• Request parameter validation.

15. Testing API Response Decoding

Many iOS applications receive JSON data from REST APIs. The application usually converts this JSON into Swift models using Codable and JSONDecoder.

Example JSON Response

{
    "id": 1,
    "name": "Wireless Headphones",
    "price": 2500
}

Corresponding Swift Model

import Foundation

struct ProductResponse: Codable, Equatable {
    let id: Int
    let name: String
    let price: Double
}

Unit Test for JSON Decoding

import XCTest
@testable import MyIOSApp

final class ProductDecodingTests: XCTestCase {

    func testDecodeProductJSON() throws {

        let json = """
        {
            "id": 1,
            "name": "Wireless Headphones",
            "price": 2500
        }
        """.data(using: .utf8)!

        let product = try JSONDecoder().decode(
            ProductResponse.self,
            from: json
        )

        XCTAssertEqual(product.id, 1)
        XCTAssertEqual(
            product.name,
            "Wireless Headphones"
        )
        XCTAssertEqual(product.price, 2500)
    }
}

Testing Invalid JSON

import XCTest
@testable import MyIOSApp

final class InvalidProductDecodingTests: XCTestCase {

    func testInvalidJSONThrowsError() {

        let json = """
        {
            "id": "wrong-value",
            "name": "Headphones",
            "price": 2500
        }
        """.data(using: .utf8)!

        XCTAssertThrowsError(
            try JSONDecoder().decode(
                ProductResponse.self,
                from: json
            )
        )
    }
}

16. Testing Network Services with URLSession

When testing a network service, developers should avoid depending on a live production API for routine unit tests. Network conditions, server availability, and remote data can change unexpectedly.

One useful approach is to inject URLSession and use a custom URLProtocol implementation to provide controlled HTTP responses.

16.1 Creating a Testable API Service

import Foundation

enum APIServiceError: Error {
    case invalidResponse
    case httpError(Int)
}

final class ProductNetworkService: ProductService {

    private let session: URLSession
    private let endpoint: URL

    init(
        session: URLSession = .shared,
        endpoint: URL
    ) {
        self.session = session
        self.endpoint = endpoint
    }

    func fetchProducts() async throws -> [Product] {

        let (data, response) = try await session.data(
            from: endpoint
        )

        guard let httpResponse = response as? HTTPURLResponse
        else {
            throw APIServiceError.invalidResponse
        }

        guard (200...299).contains(
            httpResponse.statusCode
        ) else {
            throw APIServiceError.httpError(
                httpResponse.statusCode
            )
        }

        return try JSONDecoder().decode(
            [Product].self,
            from: data
        )
    }
}

16.2 Creating a Mock URLProtocol

URLProtocol can be subclassed to intercept requests made through a configured URLSession. This allows tests to provide controlled response data without making a real network request.

import Foundation

final class MockURLProtocol: URLProtocol {

    static var requestHandler:
        ((URLRequest) throws -> (HTTPURLResponse, Data))?

    override class func canInit(
        with request: URLRequest
    ) -> Bool {
        return true
    }

    override class func canonicalRequest(
        for request: URLRequest
    ) -> URLRequest {
        return request
    }

    override func startLoading() {

        guard let handler = Self.requestHandler else {
            client?.urlProtocol(
                self,
                didFailWithError: URLError(.unknown)
            )
            return
        }

        do {

            let (response, data) = try handler(request)

            client?.urlProtocol(
                self,
                didReceive: response,
                cacheStoragePolicy: .notAllowed
            )

            client?.urlProtocol(
                self,
                didLoad: data
            )

            client?.urlProtocolDidFinishLoading(self)

        } catch {

            client?.urlProtocol(
                self,
                didFailWithError: error
            )
        }
    }

    override func stopLoading() {
        // No additional cleanup required for this example.
    }
}

16.3 Creating a URLSession for Testing

import Foundation

func makeTestSession() -> URLSession {

    let configuration = URLSessionConfiguration.ephemeral

    configuration.protocolClasses = [
        MockURLProtocol.self
    ]

    return URLSession(
        configuration: configuration
    )
}

16.4 Testing a Successful API Response

import XCTest
@testable import MyIOSApp

final class ProductNetworkServiceTests: XCTestCase {

    override func tearDown() {
        MockURLProtocol.requestHandler = nil
        super.tearDown()
    }

    func testFetchProductsSuccessfully() async throws {

        let json = """
        [
            {
                "id": 1,
                "name": "Keyboard",
                "price": 1500
            }
        ]
        """.data(using: .utf8)!

        MockURLProtocol.requestHandler = { request in

            let response = HTTPURLResponse(
                url: request.url!,
                statusCode: 200,
                httpVersion: nil,
                headerFields: [
                    "Content-Type": "application/json"
                ]
            )!

            return (response, json)
        }

        let session = makeTestSession()

        let service = ProductNetworkService(
            session: session,
            endpoint: URL(
                string: "https://example.com/products"
            )!
        )

        let products = try await service.fetchProducts()

        XCTAssertEqual(products.count, 1)
        XCTAssertEqual(products[0].name, "Keyboard")
    }
}

This example demonstrates the testing structure. In a larger test suite, protect shared mock-handler state from concurrent test execution or use an isolated handler design so parallel tests cannot overwrite each other's responses.

17. Testing HTTP Errors and Network Failures

A data service should not assume that every request succeeds. It must handle server errors, invalid responses, connectivity problems, and unexpected data.

Important HTTP Status Codes

Example: Testing a Server Error

import XCTest
@testable import MyIOSApp

final class ProductServerErrorTests: XCTestCase {

    override func tearDown() {
        MockURLProtocol.requestHandler = nil
        super.tearDown()
    }

    func testServerErrorIsReported() async {

        MockURLProtocol.requestHandler = { request in

            let response = HTTPURLResponse(
                url: request.url!,
                statusCode: 500,
                httpVersion: nil,
                headerFields: nil
            )!

            return (response, Data())
        }

        let service = ProductNetworkService(
            session: makeTestSession(),
            endpoint: URL(
                string: "https://example.com/products"
            )!
        )

        do {

            _ = try await service.fetchProducts()

            XCTFail("Expected server error.")

        } catch let error as APIServiceError {

            guard case .httpError(let statusCode) = error
            else {
                XCTFail("Unexpected API error.")
                return
            }

            XCTAssertEqual(statusCode, 500)

        } catch {

            XCTFail("Unexpected error: \(error)")
        }
    }
}

18. Testing Repository Classes

A repository acts as an abstraction between application components and data sources. It can combine information from remote APIs, local databases, and caches.

Testing a repository helps verify whether it returns the correct data and handles the behavior of its underlying dependencies.

18.1 Defining a Repository Protocol

import Foundation

protocol ProductRepository {
    func getProducts() async throws -> [Product]
}

18.2 Implementing the Repository

import Foundation

final class DefaultProductRepository: ProductRepository {

    private let service: ProductService

    init(service: ProductService) {
        self.service = service
    }

    func getProducts() async throws -> [Product] {

        return try await service.fetchProducts()
    }
}

18.3 Creating a Mock Repository

import Foundation
@testable import MyIOSApp

final class MockProductRepository: ProductRepository {

    var products: [Product] = []
    var shouldFail = false

    func getProducts() async throws -> [Product] {

        if shouldFail {
            throw URLError(.cannotConnectToHost)
        }

        return products
    }
}

18.4 Testing Repository Behavior

import XCTest
@testable import MyIOSApp

final class ProductRepositoryTests: XCTestCase {

    func testRepositoryReturnsProducts() async throws {

        let service = MockProductService()

        service.productsToReturn = [
            Product(
                id: 1,
                name: "Monitor",
                price: 15000
            )
        ]

        let repository = DefaultProductRepository(
            service: service
        )

        let products = try await repository.getProducts()

        XCTAssertEqual(products.count, 1)
        XCTAssertEqual(products[0].name, "Monitor")
    }
}

In this example, the repository is tested using a controlled service implementation. For a repository that combines remote and local storage, additional tests should verify caching, fallback behavior, data freshness, and synchronization rules.

19. Testing Local Data Services

Many iOS applications store information locally using UserDefaults, files, Core Data, SwiftData, or other persistence solutions.

Local data services should be tested to ensure that data can be saved, retrieved, updated, and deleted correctly.

19.1 Testing UserDefaults-Based Storage

Direct use of UserDefaults.standard can introduce shared state between tests. A better approach is to inject a dedicated UserDefaults instance configured with a unique suite.

import Foundation

protocol SettingsStorage {
    func saveUsername(_ username: String)
    func getUsername() -> String?
    func removeUsername()
}

final class UserDefaultsSettingsStorage: SettingsStorage {

    private let defaults: UserDefaults

    init(defaults: UserDefaults) {
        self.defaults = defaults
    }

    func saveUsername(_ username: String) {
        defaults.set(username, forKey: "username")
    }

    func getUsername() -> String? {
        defaults.string(forKey: "username")
    }

    func removeUsername() {
        defaults.removeObject(forKey: "username")
    }
}

19.2 Testing Save and Retrieve Operations

import XCTest
@testable import MyIOSApp

final class SettingsStorageTests: XCTestCase {

    var defaults: UserDefaults!
    var storage: UserDefaultsSettingsStorage!

    override func setUp() {
        super.setUp()

        let suiteName = "SettingsStorageTests.\(UUID().uuidString)"

        defaults = UserDefaults(
            suiteName: suiteName
        )

        storage = UserDefaultsSettingsStorage(
            defaults: defaults
        )
    }

    override func tearDown() {

        if let suiteName = defaults?.suiteName {
            defaults.removePersistentDomain(
                forName: suiteName
            )
        }

        storage = nil
        defaults = nil

        super.tearDown()
    }

    func testSaveAndRetrieveUsername() {

        storage.saveUsername("Rahul")

        XCTAssertEqual(
            storage.getUsername(),
            "Rahul"
        )
    }

    func testRemoveUsername() {

        storage.saveUsername("Rahul")

        storage.removeUsername()

        XCTAssertNil(
            storage.getUsername()
        )
    }
}

The example illustrates isolated UserDefaults testing. If a project uses a different persistence technology, apply the same principle: provide a test-specific storage environment and avoid modifying real user data.

20. Testing Data Mapping and Transformation

Data mapping converts information received from an external source into the format required by the application. This may involve converting API response models into domain models or presentation models.

Example: API Model and Domain Model

import Foundation

struct ProductDTO: Decodable {
    let product_id: Int
    let product_name: String
    let product_price: Double
}

struct ProductDomainModel: Equatable {
    let id: Int
    let name: String
    let price: Double
}

extension ProductDTO {

    func toDomainModel() -> ProductDomainModel {

        return ProductDomainModel(
            id: product_id,
            name: product_name,
            price: product_price
        )
    }
}

Testing the Mapping Function

import XCTest
@testable import MyIOSApp

final class ProductMappingTests: XCTestCase {

    func testDTOToDomainMapping() {

        let dto = ProductDTO(
            product_id: 5,
            product_name: "Tablet",
            product_price: 30000
        )

        let product = dto.toDomainModel()

        XCTAssertEqual(product.id, 5)
        XCTAssertEqual(product.name, "Tablet")
        XCTAssertEqual(product.price, 30000)
    }
}

21. Testing Error Handling Across Application Layers

Errors may originate from business logic, ViewModels, repositories, data services, or external APIs. A well-designed application should handle errors at the correct layer and communicate meaningful information to the next layer.

Example Error Flow

1. A data service sends a network request.
2. The server returns an error response.
3. The service converts the response into an application error.
4. The repository forwards or transforms the error according to its responsibility.
5. The ViewModel updates its state.
6. The View displays an appropriate error message.

Important Error Scenarios to Test

• Invalid user input.
• Missing required data.
• Network connection failure.
• Request timeout.
• Unauthorized API response.
• Server-side failure.
• Invalid JSON response.
• Database save failure.
• Missing local records.
• Unexpected application state.

22. Testing ViewModels with Swift Testing

Swift Testing can also be used to test ViewModel behavior. When a ViewModel is isolated to the MainActor, tests that access it should also execute on the MainActor.

Example Swift Testing ViewModel Test

import Testing
@testable import MyIOSApp

@MainActor
struct ProductViewModelSwiftTests {

    @Test
    func initialStateIsIdle() {

        let service = MockProductService()

        let viewModel = ProductViewModel(
            service: service
        )

        #expect(viewModel.state == .idle)
    }

    @Test
    func emptyResponseUpdatesState() async {

        let service = MockProductService()
        service.productsToReturn = []

        let viewModel = ProductViewModel(
            service: service
        )

        await viewModel.loadProducts()

        #expect(viewModel.state == .empty)
    }
}

23. Testing ViewModel Actions and User Events

A ViewModel often exposes methods that represent user actions. These methods should be tested to verify whether the correct business operations are triggered and the expected state changes occur.

Examples of ViewModel Actions

• loadProducts()
• refreshProducts()
• submitRegistration()
• login()
• logout()
• addToCart()
• removeFromCart()
• updateProfile()
• retryLoading()

Example: Testing a Cart ViewModel

import Foundation

struct CartItem: Equatable {
    let id: Int
    let name: String
    let price: Double
    let quantity: Int
}

@MainActor
final class CartViewModel: ObservableObject {

    @Published private(set) var items: [CartItem] = []

    var totalPrice: Double {
        items.reduce(0) {
            $0 + ($1.price * Double($1.quantity))
        }
    }

    func addItem(_ item: CartItem) {
        items.append(item)
    }

    func removeItem(id: Int) {
        items.removeAll {
            $0.id == id
        }
    }
}

Cart ViewModel Tests

import XCTest
@testable import MyIOSApp

@MainActor
final class CartViewModelTests: XCTestCase {

    func testAddItem() {

        let viewModel = CartViewModel()

        let item = CartItem(
            id: 1,
            name: "Keyboard",
            price: 1000,
            quantity: 2
        )

        viewModel.addItem(item)

        XCTAssertEqual(viewModel.items.count, 1)
        XCTAssertEqual(viewModel.items[0], item)
    }

    func testTotalPrice() {

        let viewModel = CartViewModel()

        viewModel.addItem(
            CartItem(
                id: 1,
                name: "Keyboard",
                price: 1000,
                quantity: 2
            )
        )

        viewModel.addItem(
            CartItem(
                id: 2,
                name: "Mouse",
                price: 500,
                quantity: 1
            )
        )

        XCTAssertEqual(viewModel.totalPrice, 2500)
    }

    func testRemoveItem() {

        let viewModel = CartViewModel()

        viewModel.addItem(
            CartItem(
                id: 1,
                name: "Keyboard",
                price: 1000,
                quantity: 1
            )
        )

        viewModel.removeItem(id: 1)

        XCTAssertTrue(viewModel.items.isEmpty)
    }
}

24. Testing ViewModels with Combine and Published Properties

Many UIKit and SwiftUI applications use Combine to observe changes in ViewModel properties. Testing published values helps verify that the ViewModel communicates state changes correctly.

Example ViewModel Using Published Properties

import Combine
import Foundation

@MainActor
final class CounterViewModel: ObservableObject {

    @Published private(set) var count = 0

    func increment() {
        count += 1
    }

    func decrement() {
        count -= 1
    }
}

Testing Published State

import XCTest
import Combine
@testable import MyIOSApp

@MainActor
final class CounterViewModelTests: XCTestCase {

    func testIncrementUpdatesCount() {

        let viewModel = CounterViewModel()

        viewModel.increment()

        XCTAssertEqual(viewModel.count, 1)
    }

    func testDecrementUpdatesCount() {

        let viewModel = CounterViewModel()

        viewModel.decrement()

        XCTAssertEqual(viewModel.count, -1)
    }
}

For more advanced Combine pipelines, developers can subscribe to publishers and verify emitted values, completion events, and error behavior. Tests should retain subscriptions for the duration of the assertion and clean them up when appropriate.

25. Testing Core Data and SwiftData Services

Core Data and SwiftData are persistence technologies used to store application data locally. Their service and repository layers should be tested independently from production user data.

Core Data Testing Areas

• Creating managed objects.
• Saving managed objects.
• Fetching stored records.
• Updating existing records.
• Deleting records.
• Handling duplicate records.
• Managing invalid data.
• Verifying relationships between entities.

SwiftData Testing Areas

• Creating model objects.
• Inserting records into a ModelContext.
• Saving context changes.
• Fetching records with predicates.
• Updating model properties.
• Deleting records.
• Testing relationships and sorting.

For persistence tests, create a temporary or in-memory test container when supported by the chosen framework. This prevents tests from modifying the application's actual stored records.

26. Testing Authentication and Session Services

Authentication services manage user login, logout, token handling, and session-related operations. These services should be tested carefully because they control access to protected application features.

Important Authentication Test Cases

Use test credentials and controlled authentication responses. Never place real passwords, production tokens, or private user information in test source code.

27. Understanding Test Doubles: Mock, Stub, and Fake

Test doubles are replacement objects used to isolate the component being tested from its real dependencies.

27.1 Mock

A mock records interactions and can verify whether expected methods were called with the correct values.

27.2 Stub

A stub returns predefined data when a method is called. It is useful when a test needs predictable input from a dependency.

27.3 Fake

A fake provides a simplified working implementation of a dependency, such as an in-memory repository that replaces a database.

Comparison

28. Understanding Test Coverage

Test coverage measures how much of the application source code is executed when tests run. It helps developers identify areas that may require additional testing.

Types of Code Coverage

• Line Coverage: Measures the source-code lines executed by tests.
• Function Coverage: Measures which functions or methods were executed.
• Branch Coverage: Measures whether different decision paths were executed.
• Condition Coverage: Checks whether individual Boolean conditions have been evaluated.

Example: Business Logic Branches

func shippingCost(for amount: Double) -> Double {

    if amount >= 1000 {
        return 0
    }

    return 100
}

Testing only an order amount of 1500 executes the free-shipping branch. A second test with an amount below 1000 is needed to verify the other branch.

import XCTest
@testable import MyIOSApp

final class ShippingCostTests: XCTestCase {

    func testFreeShipping() {

        XCTAssertEqual(
            shippingCost(for: 1500),
            0
        )
    }

    func testPaidShipping() {

        XCTAssertEqual(
            shippingCost(for: 500),
            100
        )
    }
}

In Xcode, configure the selected test action or test plan to collect code coverage. Review the report to identify untested areas. High coverage alone does not guarantee correctness; tests must verify meaningful behavior and important edge cases.

29. Common Testing Problems and Their Solutions

30. Best Practices for Testing ViewModels, Business Logic, and Data Services

• Keep business rules separate from interface code.
• Use dependency injection for external dependencies.
• Define protocols for services and repositories when substitution is useful.
• Test business logic independently using controlled inputs.
• Test initial, loading, success, empty, and failure ViewModel states.
• Use mocks and stubs instead of production APIs in routine unit tests.
• Test data decoding with both valid and invalid JSON.
• Test network status codes and connectivity failures.
• Use isolated storage for persistence tests.
• Test asynchronous methods using async/await where possible.
• Respect actor isolation when testing MainActor ViewModels.
• Verify important boundary conditions and error paths.
• Keep test cases independent and repeatable.
• Use meaningful test method names.
• Clean up temporary test data and shared test state.
• Run regression tests after changing business rules.
• Review code coverage without treating it as the only quality indicator.
• Run tests regularly through Xcode and CI workflows.
• Use UI tests to verify important end-to-end user journeys.
• Avoid exposing real credentials or private data in test files.

31. Practical Project: Testing a Product Listing Application

In this project, you will create a simple product listing architecture and test its business logic, ViewModel, and data service independently.

Project Requirements

• Create a Product model.
• Define a ProductService protocol.
• Implement a network-based ProductService.
• Create a ProductRepository.
• Create a ProductViewModel.
• Manage idle, loading, loaded, empty, and failed states.
• Create a mock service for unit testing.
• Test business rules for product pricing.
• Test ViewModel state changes.
• Test JSON decoding and API errors.

Step 1: Create the Product Model

import Foundation

struct Product: Codable, Equatable, Identifiable {
    let id: Int
    let name: String
    let price: Double
}

Step 2: Create the Service Protocol

protocol ProductService {
    func fetchProducts() async throws -> [Product]
}

Step 3: Create the Business Logic

struct ProductPricingService {

    func calculateTotal(
        products: [Product]
    ) -> Double {

        return products.reduce(0) {
            $0 + $1.price
        }
    }

    func calculateAveragePrice(
        products: [Product]
    ) -> Double {

        guard !products.isEmpty else {
            return 0
        }

        return calculateTotal(products: products)
            / Double(products.count)
    }
}

Step 4: Create the ViewModel

import Foundation

@MainActor
final class ProductListViewModel: ObservableObject {

    enum State: Equatable {
        case idle
        case loading
        case loaded([Product])
        case empty
        case failed(String)
    }

    @Published private(set) var state: State = .idle

    private let service: ProductService

    init(service: ProductService) {
        self.service = service
    }

    func loadProducts() async {

        state = .loading

        do {

            let products = try await service.fetchProducts()

            state = products.isEmpty
                ? .empty
                : .loaded(products)

        } catch {

            state = .failed(error.localizedDescription)
        }
    }
}

Step 5: Create the Mock Service

final class MockProductService: ProductService {

    var products: [Product] = []
    var shouldFail = false

    func fetchProducts() async throws -> [Product] {

        if shouldFail {
            throw URLError(.notConnectedToInternet)
        }

        return products
    }
}

Step 6: Test Business Logic

import XCTest
@testable import MyIOSApp

final class ProductPricingServiceTests: XCTestCase {

    let pricingService = ProductPricingService()

    func testCalculateTotal() {

        let products = [
            Product(
                id: 1,
                name: "Keyboard",
                price: 1000
            ),
            Product(
                id: 2,
                name: "Mouse",
                price: 500
            )
        ]

        let total = pricingService.calculateTotal(
            products: products
        )

        XCTAssertEqual(total, 1500)
    }

    func testCalculateAveragePrice() {

        let products = [
            Product(
                id: 1,
                name: "Keyboard",
                price: 1000
            ),
            Product(
                id: 2,
                name: "Mouse",
                price: 500
            )
        ]

        let average = pricingService.calculateAveragePrice(
            products: products
        )

        XCTAssertEqual(average, 750)
    }

    func testAveragePriceForEmptyProducts() {

        let average = pricingService.calculateAveragePrice(
            products: []
        )

        XCTAssertEqual(average, 0)
    }
}

Step 7: Test the ViewModel

import XCTest
@testable import MyIOSApp

@MainActor
final class ProductListViewModelTests: XCTestCase {

    func testSuccessfulLoading() async {

        let service = MockProductService()

        service.products = [
            Product(
                id: 1,
                name: "Keyboard",
                price: 1000
            )
        ]

        let viewModel = ProductListViewModel(
            service: service
        )

        await viewModel.loadProducts()

        XCTAssertEqual(
            viewModel.state,
            .loaded(service.products)
        )
    }

    func testEmptyLoading() async {

        let service = MockProductService()

        let viewModel = ProductListViewModel(
            service: service
        )

        await viewModel.loadProducts()

        XCTAssertEqual(
            viewModel.state,
            .empty
        )
    }

    func testFailedLoading() async {

        let service = MockProductService()
        service.shouldFail = true

        let viewModel = ProductListViewModel(
            service: service
        )

        await viewModel.loadProducts()

        if case .failed = viewModel.state {
            XCTAssertTrue(true)
        } else {
            XCTFail("Expected failed state.")
        }
    }
}

Step 8: Execute the Tests in Xcode

1. Open the project in Xcode.
2. Create or select a unit-testing target.
3. Add the model, service, repository, and ViewModel files to the application target.
4. Add the test files to the appropriate test target.
5. Confirm that the test target can import the application module.
6. Select a supported simulator or test destination.
7. Run the business-logic tests.
8. Run the ViewModel tests.
9. Run the data-service tests.
10. Review the test results and fix any failures.
11. Enable code coverage when required.

Project Testing Checklist

• Product model values are initialized correctly.
• Product pricing calculations return the expected results.
• Empty product collections are handled correctly.
• ViewModel starts in the idle state.
• ViewModel handles successful data loading.
• ViewModel handles empty responses.
• ViewModel handles service errors.
• API response decoding works correctly.
• Invalid JSON is rejected.
• HTTP error responses are handled correctly.
• Test dependencies do not access production services.

32. Practice Exercises

1. Create a LoginViewModel and test its initial state.
2. Write unit tests for email and password validation.
3. Create a mock authentication service and test successful login.
4. Test login failure and session expiration.
5. Create a shopping cart business-logic component.
6. Write tests for cart totals, discounts, and delivery charges.
7. Create a repository that retrieves user records from a service.
8. Test repository behavior when the service returns an empty response.
9. Create a data service that decodes JSON into Swift models.
10. Test the data service with invalid JSON and HTTP 500 responses.
11. Create an isolated UserDefaults storage service and test save and delete operations.
12. Test asynchronous ViewModel operations using async/await.
13. Write parameterized tests for a pricing calculation.
14. Configure an Xcode test plan for business-logic and ViewModel tests.
15. Measure code coverage and identify untested branches.

33. Interview Questions and Answers

Q1. What is a ViewModel in iOS?

A ViewModel is a component in the MVVM architecture that manages presentation-related state, prepares data for the View, and coordinates application operations.

Q2. Why should ViewModels be tested independently?

Independent testing verifies state changes and application behavior without requiring the complete user interface. It also helps identify errors more quickly.

Q3. What is business logic?

Business logic contains application rules such as calculations, validation, pricing, eligibility checks, and order-processing decisions.

Q4. Why should business logic be separated from the View?

Separating business logic from the View improves reusability, maintainability, and testability. It also prevents interface changes from unnecessarily affecting application rules.

Q5. What is dependency injection?

Dependency injection is a technique in which an object receives its required dependencies from an external source instead of creating them internally.

Q6. Why are protocols useful in testing?

Protocols define contracts that multiple implementations can follow. They allow real services to be replaced with mocks or stubs during testing.

Q7. What is a mock service?

A mock service is a test implementation that replaces a real service and provides controlled behavior for a test.

Q8. What is the difference between a mock and a stub?

A stub mainly provides predefined responses, while a mock can also record interactions and verify whether expected calls occurred.

Q9. What is repository testing?

Repository testing verifies how a repository retrieves, stores, transforms, or coordinates data from different sources.

Q10. How can API services be tested without an internet connection?

Developers can inject URLSession, use custom URLProtocol implementations, or provide mock service objects that return controlled responses.

Q11. What is the Arrange-Act-Assert pattern?

Arrange prepares the test environment, Act executes the operation, and Assert verifies that the result matches the expected behavior.

Q12. How do you test asynchronous ViewModels?

Use async test methods and await the ViewModel operation before checking its final state. XCTest expectations can be used for callback-based operations.

Q13. Why is MainActor important in ViewModel testing?

A ViewModel isolated to MainActor must be accessed according to actor-isolation rules. Tests that interact with such a ViewModel should also execute on the MainActor.

Q14. What is data mapping?

Data mapping converts information from one representation into another, such as converting an API response model into a domain model.

Q15. What is test isolation?

Test isolation ensures that one test does not depend on another test's state, data, or execution order.

Q16. What is parameterized testing?

Parameterized testing runs the same test logic with multiple input values to verify different scenarios efficiently.

Q17. How do you test a ViewModel's loading state?

Configure a controlled service response, call the loading operation, and verify that the ViewModel reaches the expected state. If the loading state must be observed while a request is in progress, use a controllable asynchronous mock.

Q18. How do you test an empty API response?

Configure a mock service to return an empty collection and verify that the ViewModel or repository handles the empty result correctly.

Q19. Why should production APIs not be used for routine unit tests?

Production APIs can change, become unavailable, or return different data. Mocked responses make unit tests faster, more predictable, and easier to repeat.

Q20. What is the difference between a unit test and an integration test?

A unit test verifies a small component independently, while an integration test verifies that multiple components work together correctly.

34. Quick Revision Checklist

• ViewModels manage presentation state and coordinate operations.
• Business logic contains application rules and calculations.
• Data services communicate with APIs and local storage.
• Repositories provide a consistent data-access abstraction.
• MVVM separates the View, ViewModel, and Model responsibilities.
• Dependency injection makes components easier to test.
• Protocols allow real and test implementations to be substituted.
• Arrange-Act-Assert organizes test cases.
• XCTest supports unit and asynchronous testing.
• Swift Testing provides modern test declarations and expectations.
• Mocks and stubs provide controlled dependency behavior.
• Business logic tests should cover valid, invalid, and boundary inputs.
• ViewModel tests should cover initial, loading, success, empty, and failure states.
• Data-service tests should cover decoding, HTTP errors, and network failures.
• URLProtocol can help intercept network requests during testing.
• Local storage tests should use isolated test data.
• Async methods should be tested after their operations complete.
• Code coverage helps identify untested areas.
• Tests should be independent, repeatable, and meaningful.

35. Conclusion

Testing ViewModels, Business Logic, and Data Services is an important part of building reliable iOS applications. Each component has a different responsibility and should be tested according to its behavior.

ViewModel testing verifies presentation state, user actions, and dependency coordination. Business-logic testing verifies calculations, validation rules, and application decisions. Data-service testing verifies API communication, response decoding, error handling, and local storage operations.

Using XCTest, Swift Testing, dependency injection, protocols, mocks, stubs, and isolated test environments helps developers create reliable and maintainable test suites. A strong testing strategy combines focused unit tests with integration tests and UI tests for important end-to-end workflows.

By applying these techniques throughout development, iOS developers can detect defects earlier, improve application architecture, reduce regression problems, and deliver more dependable applications.

36. Official Learning Resources

• Apple – Testing in Xcode
• Apple – XCTest Documentation
• Apple – Swift Testing Documentation
• Apple – Asynchronous Tests and Expectations
• Apple – URLSession Documentation
• Apple – ObservedObject Documentation
• Apple – Combine Documentation

Course: iOS App Development – JustAcademy

Explore the Course: View iOS Training

Register for a Demo: Register for Course Demo

Visit JustAcademy: JustAcademy Official Website